home *** CD-ROM | disk | FTP | other *** search
- Path: gate.net!pslfl2-8
- From: bhutto@gate.net (William Hutto)
- Newsgroups: comp.lang.c
- Subject: Re: Runtime error when stressing application
- Date: 17 Jan 1996 00:07:13 GMT
- Organization: CyberGate, Inc.
- Message-ID: <4dhejh$18p2@news.gate.net>
- References: <4dgdjd$1ko@erinews.ericsson.se>
- NNTP-Posting-Host: pslfl2-34.gate.net
- X-Newsreader: News Xpress Version 1.0 Beta #4
-
- In article <4dgdjd$1ko@erinews.ericsson.se>,
- ebcjeg@ebc.ericsson.se (Jan Granqvist) wrote:
- >Hello everybody.
- >
- >I've received this strange fault which occurs when stressing this
- >application I'm working on, which runs under windows.
- >
- >To make things short.
- >I call lstrlen ( pointer ), where pointer is composed by combining a
- >pointer and an offset.
- >
- > dwDestAddressSize = lstrlen( (LPCSTR)(lp_ForwardingInfo + dwOffset ))
-
- Not knowing what type lp_ForwardingInfo is, I'll guess it points to something
- 0x18 bytes in size. Right? If your compiler does pointer arithmetic properly,
- it did exactly what you told it to. If you want to do the pointer arithmetic
- yourself as such, you should first cast lp_ForwardingInfo to LPCSTR assuming
- that resolves to a BYTE size granularity. e.g.:
-
- dwDestAddressSize = lstrlen( ((LPCSTR)lp_ForwardingInfo)+ dwOffset );
-
- Assuming that the sizeof(*lp_ForwardingInfo) is 0x18, did you realize that if
- dwOffset had been 1 it would have yielded the correct results (in your
- example)? It (the compiler) apparantly multiplied dwOffset by 0x18 which made
- me think you must have been trying to access the second element in an array
- (lp_ForwardingInfo[1]). The compiler thought you were trying to access the
- 25th element (lp_ForwardingInfo[24]), which happens to be the difference
- between the base (0x0910) and the value you passed to this function (0x0B50).
- The compiler will do the math for you if you let it.
-
- Bill
-
- >+ 1;
- >
- >When stressing this application CodeGuard complains about an invalid
- >string pointer.
- >So, I changed from lstrlen to strlen, which resulted in a GPF, which
- >in turn I could catch in the debugger.
- >
- >The call stack indicated a fault in strlen. I took a look at the
- >stack, and saw that the
- >argument pushed on the stack was wrong, the offset to the pointer was
- >totally wrong, the segment was however correct.
- >
- >d SS:BP
- >
- > 0x43A7 correct segment value
- > 0x0B50 wrong offset value, should have been 0x0928
- > 0x47C7 return address
- > 0x4235 return address
- >
- >So, I took a look on the variables which creates the argument to
- >strlen, and these showed the proper values.
- >
- > lp_ForwardList 0x43A7:0x0910
- > dwOffset 0x18
- >
- >I then created a dummy variable
- >
- > lpDummy = (LPCSTR)(lp_ForwardingInfo + dwOffset );
- > lpDummy = lpDummy;
- >
- >to see if it always came up with this result. And, it did. But still
- >the variables for creating the dummy variable were right. So, I
- >thought to myself, weird shit.
- >I was thinking about a corrupt stack, but the return address and
- >segment values were right.
- >I then created a dummy function with three arguments
- >
- > void myfunc ( DWORD, LPSTR, DWORD );
- >
- >that only calls strlen, which I called
- >
- > myfunc ( dwResult, (LPSTR)lp_ForwardingInfo, dwOffset );
- >
- >to see which values pushed on the stack were wrong.
- >But after I did this small change, it works, I couldn't get a GPF.
- >Now, somebody tell me, what's going on.
- >
- >It was compiled using VC++ 1.51, large model, no optimization.
- >
- >I'm waiting eagerly for reply.
- >
- >
-